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ABSTRACT 

This study investigates current thinking on the systems 
approach to management and its applicability to the project 
manager as an individual in the Naval laboratory, specifi- 
cally the Naval Electronics Laboratory Center (NELC) in San 
Diego, California. It looks at the NELC organization, 
management roles, conflicts, interfaces, problems and some 
procedures which are used by project managers in planning 
and controlling. 

The authors conclude that laboratory project managers 
can be more effective if they have some management orienta- 
tion or philosophy, and that the management philosophy that 
best fits the laboratory environment is the systems approach. 
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I. INTRODUCTION 



A. THE PROBLEM 

The Naval Electronics Laboratory Center in San Diego, 
California is one of seventeen Naval laboratories which 
conducts research and development projects. The projects 
within the laboratory are normally headed by a designated 
project manager who is responsible to both the project 
sponsor and the laboratory. The majority of these project 
managers have technical backgrounds and are technically 
oriented; they are engineers who have been thrust into a 
difficult job which requires both engineering and managerial 

talent. By background, experience and education they are 

/ 

skilled in the required technical areas but have generally 
not had to give much thought to managerial problems. 

The problem faced by the laboratory project manager is 
first to recognize the importance of managerial skills, and 
then do something about acquiring those skills so he can 
perform more effectively. Whether these engineers should 
receive managerial training before they move from the lab- 
oratory bench to the position of project manager is no 
longer a question. Today, research and its applications 
are becoming more management intensive and all phases of 
the acquisition process are receiving detailed attention 
at every level In the Navy. An increased insistence on 
accountability and performance point to a need for a higher 
degree of management orientation. 
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In this paper, the management problems which the pro- 
ject manager must confront in the Naval laboratory environ- 
ment and a view of management which can be used to cope with 
these problems will be presented. 

B. THE HYPOTHESIS 

Naval laboratory project managers in general are tech- 
nically oriented, have technical backgrounds but are some- 
times lacking in the management orientation which is 
important to the project manager. The transition from 
engineer to project manager requires some change of motiva- 
tion, new skills must be learned and one's scope and view 
must be expanded. Senior managers often give little atten- 
tion to these needs, for they made the transition from 
engineer or scientist to manager long ago and have outgrown 
the difficulties they felt at the time. The management 
training offered is often poorly related to the problems 
involved in project management and the new project manager 
is left to find his own way, sometimes at the project's and 
organization's expense. 

Therefore, it is the hypothesis of this paper that the 
laboratory project manager needs some management orientation 
to successfully deal with the management problems inherent 
in a project. This does not mean to imply that his techni- 
cal orientation is any less important or that technical 
skills should suffer because he develops a management phi- 
losophy. The authors believe that for a project manager to 
effectively manage a project, he needs a management orientation 
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to compliment his technical ability. In addition, the 
management orientation or philosophy which he should use 
is the systems approach to management. He cannot walk 
around in a world of his own but must realize that "every- 
thing depends on everything else."' 1 ' 

C. THE APPROACH 

The purpose of the investigations and research conducted 
was to examine the techniques of control and management used 
by project managers in a Naval laboratory and determine the 
organizational structure and procedures which form the 
basis of the laboratory's working relationships. In addi- 
tion, various articles and books were researched to confirm 
the authors' thoughts as to what constitutes the total sys- 
tems approach to management. 

The approach to this study consisted of three basic 
phases. The first phase involved three visits to NELC at 
San Diego to conduct interviews with project managers, re- 
search engineers, operations analysts, contracting special- 
ists, contracting officers and a project manager outside 
2 

NELC. This phase also included one visit to the Naval 
Weapons Center, China Lake, California in an effort to 
discover problems and techniques common to project managers 



^Cleland, D. I. and King, V/. R. , Management: A Systems 

Approach , p. 1*12 , McGraw-Hill, 1972. 

2 

An interview was conducted with Mr. John Heising, Viking 
Program Manager for Teledyne Ryan in San Diego, to obtain a 
feeling for some procedures and techniques used by a non- 
laboratory project manager. 
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in both NELC and NWC through interviews with personnel in 
positions similar to those interviewed earlier. Over a six 
month period, a total of nineteen interviews were conducted 
and the laboratory/project organization and procedures were 
reviewed in depth. 

The second phase of the approach involved primarily 
library research into the theory of the systems approach to 
management. The current thought and direction of the sys- 
tems theory was reviewed along with its application in 
various organizations. The timing of this phase overlapped 
the other two phases and a portion of it was accomplished 
between visits to the laboratories. 

The third phase was the main thrust of this paper and 
consisted of an application of the systems approach to the 
laboratory project manager’s environment through an analysis 
of the data obtained. 
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II. THE SYSTEMS APPROACH TO MANAGEMENT 



A. INTRODUCTION 

This chapter will discuss the concept of a systems 
approach to management. The application of the systems ap- 
proach to project management in a Naval laboratory will be 
discussed in Chapter IV. 

In current writings on the subject of total systems ap- 
proach, there is no obvious agreement as to the meaning of 
"total systems." Some authors contend that while a total 
systems approach is theoretically possible, practically 
speaking it is not feasible. Other authors believe that 
the key utility of the systems viewpoint is not in its aca- 
demic value, but rather its applicability to the real world. 
There are some indications that the term "total systems ap- 
proach" is used rather loosely and with little consistency 
as to its meaning. Therefore, it seems appropriate at this 
time to provide an understanding of the term which will fit 
with the concept and application as intended for this paper. 

B. THEORETICAL ASPECTS 

Before "systems approach" is discussed, an understanding 
of the various meanings of the word system should be presented. 



^Brooker, W. M. A., "The Total Systems Myth," in Emerging , 
Concepts in Management , ed . by Wortinan, M. S., Jr. and 
Luthans , F. , pp . 362-370, Macmillan, 1969- 

J| 

Cleland , op. cvt. 3 p. 1*16. 
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The Dictionary defines system as: 



...1. a set or arrangement of things so related or 
connected as to form a unitary or organic whole: 
as, a solar system , irrigation system , supply system . 
2. the world or universe. 3. the body considered 
as a functioning organism: as, my system needs ton- 

ing up. 4. a set of facts, principles, rules, etc. 
classified or arranged in a regular, orderly form so 
as to show a logical plan linking the various parts. 

5. a method or plan of classification. 6. a regu- 
lar, orderly way of doing something; order; method; 
regularity. 7* a number of bodily organs acting 
together to perform one of the main bodily functions: 
as, the circulatory system , digestive system . 8. 
an arrangement of rocks showing evidence, as through 
fossils, of having been formed during a given geolog- 
ical period: as, the Devonian system . 9. a group 

of transportation lines under a common owner. 10. in 
chemistry, a group of substances in or approaching 
equilibrium: a system with two components is called 

binary, one with three, ternary, etc.... 5 

There appears to be as many definitions of system as there 

are texts written on the systems approach. As one text on 

systems theory and management states: 

The concept of a "system*' is getting a great deal of 
attention in both industrial and academic circles. 
Unfortunately, the word has many meanings; for pur- 
poses of this discussion, a system is simply an as- 
semblage or combination of things or parts forming 
a complex whole. One of its most important charac- 
teristics is that it is composed of a hierarchy of 
subsystems . ° 

Some of the earlier and more influential (judging from the 
number of times they are referenced in readings on system 
theory) proponents of the systems approach, Johnson, Kast 



q 

^ Webster's New World Dictionary of the American Language , 
College Edition, ed . by Guralnik, D. B. and Friend, J. H., 
pp. 1480-81,' World Publishing, 1964. 

^Martin, E. W. , Jr., "The Systems Concept," in Systems , 
Organizations, Analysis, Management: A Book of Readings , 

ed . by Cleland, D. I. and King, W. R . , pp . 49-90 , McGraw-Hill , 
1969. 
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and Rosenzweig, define a system initially as: 

..."an organized or complex whole, an assemblage 
or combination of things or parts forming a complex 
or unitary whole." The term system covers an ex- 
tremely broad spectrum of concepts. 7 

and later as: 

...an array of components designed to accomplish 
a particular objective according to plan. There 
are three significant points to this definition. 

First, there must be a purpose, or objective, which 
the system is designed to perform. Second, there 
must be a design or an established arrangement of 
the components. Finally, inputs' of information, 
energy, and materials must be allocated according 
to plan. 8 

Melvin B. Kline and Melvin W. Lifson, in lecture notes 

prepared for a System Engineering course at the University 

of California, Los Angeles, define a system as follows: 

A system is a set of elements organized to perform 
a set of designated functions in order to achieve 
desired results. An element is a set of resources 
organized to perform some highly interrelated sub- 
set of the desired system functions . The resources 
which comprise an element include personnel, ma- 
terial, equipment, facilities, and information. 9 

There are many more definitions of a system which could 
be presented. However, the definitions we have chosen to 
include appear to have a common set of ideas throughout. 

They can be construed to include the assemblage or arrange- 
ment of parts, things, components or elements organized into 



v 

Johnson, R. A., Kast, F. E., and Rosenzweig, J. E., 
The Theory and Management of Systems , p. *1 , McGraw-Hill, 

^Ibid . , p. 91 . 

^Kline, M. B. and Lifson, M. W. , System Engineering , 
p. 1-1*1, Lecture Notes, 1970. 
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a complex, unitary whole or structure. Therefore, for pur- 
poses of this paper, a system can be defined to include the 
Interaction, interdependency and integration of the combina- 
tion of elements into a unitary whole by means of a plan to 
achieve desired results. Obviously, the meaning or concept 
of the word "system" carries with it a much greater amount 
of thought and in-depth study than is generally realized. 

An application of a system which will be used in this 
paper is seen in the Naval laboratory organization which can 
be viewed as a man-made system having interaction with its 
environment (i.e. sponsor, contractor, workcenters, special- 
ists, other government agencies, etc.). It is a system of 
interrelated parts working in conjunction with each other 
in order to accomplish desired results, both of the organiza- 
tion and the individuals. 

Now that the term "system" has been defined and it is 
understood how it will be used in this paper, what is the 
systems approach to management or the systems concept? The 
systems concept is more widely discussed than understood. 

It has been widely applied by people who did not know they 
were doing so and has often been ignored by people who 
should know better."^ 

The systems approach primarily involves the idea that 
every organization is a system and is composed of many in- 
terrelated parts , all of which affect each other and the 



10 Cleland, D. I. and King, W. R. , Systems , Organizations , 
Analysis, Management: A Book of Readings , p. h'( , McGraw-H ill, 

1969 - 
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total system In some manner. Therefore, a manager’s main 
concern should be given to the overall effectiveness of the 
system (rather than to the effectiveness of the individual 
parts or subsystems) and to the inter-dependencies of the 
elements of the system. This concept can be applied to any 
organization and any level in an organization. In applying 
the systems approach, overall organizational objectives and 
goals must be considered rather than just considering the 
parochial objectives of a particular subsystem. The manager 
must consider overall objectives and, if necessary, make 
decisions which are sometimes non-optimal for his subsystem.' 1 '''' 
This does not imply that subsystems will always be non- 
optimized, for some decisions which are optimal for the 
total system will also be optimal for the subsystem. 

The theory of systems concepts closely relates to a 

general theory of management that has evolved. It focuses 

on the fundamental processes which are essential for any 

type of organization — business, government, educational, 

social and other activities — where human and physical 

12 

resources are combined to meet certain objectives. These 
fundamental processes have been described in various ways, 
but the four basic functions of planning, organizing, con- 
trolling and communicating have received general acceptance. 



11 

12 



Ibid. 

J ohnson , 



op. 



cit . , 



p. 1*) . 
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Richard Johnson, et. al . , defines them in terms of systems 
concepts as follows: 



Planning . The managerial function of planning is 
one of selecting the organizational objectives and 
the policies, programs, procedures, and methods 
for achieving them. The planning function is es- 
sentially one of providing a framework for inte- 
grated decision making and is vital to every 
man-machine system. 

Organizing . The organizing function helps to co- 
ordinate people and resources into a system so that 
the activities they perform lead to the accomplish- 
ment of system goals. This managerial function 
involves the determination of the activities re- 
quired to achieve the objectives of the enterprise, 
the departmentation of these activities, and the 
assignment of authority and responsibility for their 
performance. Thus the organizing function provides 
the inter-connection, or intertie, between the 
various subsystems and the total organizational sys- 
tem . 

Control . The managerial function of control is es- 
sentially that of assuring that the various organi- 
zational subsystems are performing in conformance 
to plans. Control is essentially the measurement 
and correction of activity of the subsystems to 
assure the accomplishment of the overall plan. 
Communication . The communication function is pri- 
marily one of the transfer of information among 
decision centers in the various subsystems through- 
out the organization. The communication function 
also includes the interchange of information with 
the environmental forces. 13 

These four functions should not be considered as independent 

activities nor should any time sequence be implied. It is 

part of the systems concept to realize how interlocked they 

are. Another list of the functions of management is plan- 

ill 

ning, organizing, staffing, directing and controlling. 
Whatever terms are used, the advantage of approaching any 



13 Ibid ., pp. 14-15. 

.Koontz, H. and O'Donnell, C., Principles of Management 
An Analysis of Managerial Functions, pp. "4 7-49, McGraw-Hill, 
l972^ 
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area or problem as a system so the critical variables and 

constraints and their interaction with each other can be 

seen is obvious. "It forces scholars and practitioners in 

the field to be constantly aware that one single element, 

phenomenon, or problem should not be treated without regard 

15 

for its interacting consequences with other elements." 

This is exemplified in the case of the four managerial 
functions or processes. 

The planning, organizing, controlling and communicating 
functions form the structure, means, measure and environment 
of the decision-making process. Management is basically the 
coordination and integration of all resources (both human 
and technical) to accomplish specific results."^ The total 
management process includes coordinating the functions so 
as to meet the overall objectives of the system. Therefore, 
the systems approach also involves coordinating and inte- 
grating the management functions of planning, organizing, 
controlling and communicating in .a systematic manner. 

C. CURRENT THOUGHTS ON THE SYSTEMS APPROACH 

The systems concept has been in existence for many 
years; but in the past decade, a general systems theory has 



15 Ibid ., p. 14. 

*1 f) 

°Scanlan, B. K., Principles of Management and Organi - 
zational Behavior, p. 5, John Wiley & Sons, 1973* * 
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been developed to provide a basis for the integration of 
managerial techniques and scientific knowledge across a 
broad spectrum. 

In one of the more current texts on the systems con- 
cept, Edgar Huse and James Bowditch address the subject 

from three perspectives — the structural-design view of 

17 

management, work flow and the human perspective. Regard- 
less of the perspective, the organization is treated as an 
18 

open system which affects and is affected by its environ- 
ment. The inter-dependencies among the subsystems are as 
important as the individual subsystem. Organizations try 
to achieve a balance among the subsystems, but the balance 
is continually changing with the need to adapt to an un- 
stable environment and the inter-dependence of the parts. 

The organization must be viewed from all three perspectives 
(as formal organizations, as flow systems and as interacting 
humans) for a complete understanding. To use the systems 

19 

approach, it is necessary to integrate these perspectives. 

Another view of the systems concept which is more 
engineering/problem solving oriented is in the field of 
systems engineering. 



17 

Huse, E. P. and Bowditch, J. L., Behavior in Organ - 
izational Behavior , p. 5> John Wiley & Sons, 1973- 

18 

A system is an "open system" when there are constant 
relationships to its environment, or inputs from the en- 
vironment and outputs to the environment. 

"^Huse, op. ait., pp . 
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Experience has shown that the successful planning 
and acquisition of large complex systems requires 
the "systems approach." The systems approach 
recognizes the interrelationships which tie a sys- 
tem together; it recognizes that factoring out a 
part of a problem by neglecting the interactions 
among subsystems and components increases signifi- 
cantly the probability that a solution to the prob- 
lem will not be found; it requires that the 
boundaries of the system be extended outward as 
far as is required to determine which interrela- 
tionships are significant to the solution of the 
problem . 20 

This systems engineering view was generated in part by in- 
adequacies of military system acquisition and operation 

and considers systems engineering as the application of the 

21 

systems approach. In this paper, a broader view of the 
systems approach is taken and it is considered as more of 
a management philosophy than a problem solving or engineer- 
ing technique. 

Another view, presented by Richard Johnson, et . al . , 

of the systems concept is to describe the flow process, 

analyze each segment and explore relationships of parts to 

the whole. In this way, subsystems which fail to optimize 

22 

their contribution to the total system can be recognized. 
This view thinks of the organization as an integrated whole 
where each subsystem or part is associated with the total 
operation and its structure is created by many subsystems 



20 

Kline, op. ctt . , p. 1-12. 

21 Ibid. } p. 1-13. 

22 

Johnson, op. cit . , p. 90. 
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arranged in hierarchial order. The output of the lower sub- 
systems is input for higher subsystems, which is input for 

23 

the next higher level, etc. 

In this paper, the systems concept is viewed as a useful 
way of thinking about the job of managing. It provides a 
framework for visualizing environmental factors and allows 
recognition of the functions of subsystems. Systems in 
which managers function are complex and the systems concept 
fosters a way of thinking which helps clear up some of the 
complexity while at the same time helps the manager recog- 
nize the nature of complex problems so he can better oper- 
2k 

ate within the system. It is important to recognize that 

every organizational system is part of a larger system with 

which it interacts and influences, and that all systems are 

in a constant state of change — they are created, operated, 

25 

revised and sometimes eliminated. 

D. THE TOTAL SYSTEM APPROACH 

The "total system approach" is basically a philosophy 
or concept of management. The management can involve sys- 
tems engineering, business management, developmental en- 
gineering or project management, to name a few. Regardless 



^ Ibid . , p . 91 • 

2k 

Johnson, R. A., Kast, F. E. and Rosenzweig, J. E., 
"Systems Theory and Management," in Emerging Concepts in 
Management , ed. by Wortman, M. S. , Jr. and Luthans, F., 
p. 331 , Macmillan, 1969 . 



25 



Ibid. 
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of the area or discipline in which it is used, it is a 
way of thinking or philosophy for a manager rather than a 
list of techniques, principles, "recipe book" or body of 
knowledge . 

It is a concept which provides the manager with a frame- 
work he should use to visualize the system in which he op- 
erates and the manner in which his area of responsibility 
is constrained and influenced. It recognizes the systems 
concept and the complex interrelationships which exist in 
every organization of subsystems. If understood by the 
manager, it will help to remove some of the complexity of 
his job on the one hand; and on the other, help him to 
recognize the very complex nature of the structure within 
which he works. 

Some authors have implied that the concept of "general 
systems" has been translated into "total systems." While 
general systems theory is a valid concept because its pro- 
ponents realize its limitations, the total systems concept 
is not valid because it cannot explain the way things are 

or predict the way things are going to be (regarding the 

. 2 ^ 
most significant aspect of the organization, people). 

However, the meaning of the term "total system" as used here 
is not intended to imply a specific systems analysis tech- 
nique or management information system which will solve all 



26 

Brooker, op. cit. } p. 365- 
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the problems which a manager encounters or predict problems 
which will arise. Rather, total system implies a management 
outlook which is oriented toward the goals and objectives 
that have been established for the whole or total system . 

To use the total system approach, the manager must be 
able to see beyond the immediate consequences of any de- 
cision or change which he makes in his subsystem of the or- 
ganization. No one subsystem of an organization can function 
effectively without others and any action taken by one will 

have effects which can be traced throughout the total sys- 

27 

tem. When a manager makes a decision with no thought of 
its effect on other parts of the organization or the organi- 
zation as a whole, he is not using the total system approach 
as viewed here . 

In the following chapter, the Naval Electronics Labora- 
tory . Center ' s mission, personnel, funding, organization, 
manager roles, conflicts and interfaces will be presented 
in order to gain a clearer understanding of why and how the 
system approach might be used by laboratory project managers. 
Chapter IV presents the history of project management, NELC 
project management, NELC project manager's profile, some 
examples 'of problems encountered in planning and control- 
ling and examples of use/nonuse of the systems approach. 
Throughout the discussion which follows, the systems concept. 



27 

Cleland, Management , p. 1*12. 
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or making decisions (whether planning or control decisions) 
in the light of their effect on other subsystems in the 
organization, must be kept in mind. Understanding the com- 
plexity of the Naval laboratory, the many interfaces with 
which the project manager must deal and some of the problems 
encountered should make the value of the systems approach 
to management clear. 



III. THE NAVAL ELECTRONICS LABORATORY CENTER 



A. INTRODUCTION 

Government laboratories can trace their history to the 
establishment of the Springfield Arsenal in 1790. Over the 
years Naval laboratories have played a major role in the 
development of weapons systems and have been responsible 

2 g 

for technological advances in many areas. 

Today , the prime mission of the Naval Electronics Labo- 
ratory Center (NELC) is to be the principle Navy Research, 
Development, Test and Evaluation center for electronics 
technology and command, control and communication concepts 
and systems. More specifically, it is the primary in-house 
research and development capability for the following: 

• Navy and Marine Corps systems, subsystems and 
technologies 

• command, control and communications 

• electromagnetic surveillance, identification and 
navigation 

• electronic warfare 

• shipboard internal. communications 

• information collection, processing, transmission and 
display 

• computer and software technology 

• automatic test and monitoring equipment 
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°For a complete treatment of Naval laboratory history 
see Munro, W. S. and Brennan, A. C., Project Management as 
Related to Weapons Development in Navy Research and Develop - 
ment Organizations , Master's Thesis, Naval Postgraduate 
School, Monterey, California, 1973- 
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• electro-optics and optics 

• electronic materials, components and circuits 

• electromagnetic propagation 

• antennas and antenna systems 

• human factors technology 

• electronic systems effectiveness engineering 

• bioelectronics. 

The Naval Electronics Laboratory includes over eighty 
military personnel and fifteen hundred civilian personnel. 
More than three hundred of these hold advanced degrees and 
the proportion of advanced degrees has increased over the 
years. (Figure 1 gives an NELC educational profile from 
fiscal year 69 through 74.) Approximately one-half of all 
NELC personnel are professionals . Figure 2 gives examples 
of NELC professionals along with its professional mix. 

The laboratory is under the Navy Industrial Funding 
System and operates much like an individual business enter- 
prise, with complete accountability to its customer and 
Navy fiscal management. All funds, with few exceptions, 
are received from sponsors as the result of successful pro- 
ject bidding in competition with other research and develop- 
ment organizations . The exceptions are military construction 
funds and a small amount of equipment and minor construction 
and repair funds provided by the Director of Laboratory 
Programs. The laboratory fiscal 73 budget, for example, 
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NELC CIVILIAN EDUCATIONAL PROFILE 




□ NO DEGREE 




DOCTORATES 




MASTERS 




BACHELORS 



7 / 31 / 7 - 



Figure 1. 
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NELC PROFESSIONALS MIX 



FISCAL YEAR 

69 70 71 72 73 74 















/ H* 


ENGINEERS 


342 


403 


456 


495 


511 


530 


PHYSICISTS 


70 


99 


108 


114 


112 


111 


OPERATIONS RESEARCH 


21 


31 


32 


33 


36 


38 


ANALYSTS 














PSYCHOLOGISTS 


17 


17 


18 


20 


19 


19 


■' MATHEMATICIANS 


40 


51 


53 


42 


31 


30 


OTHER 

■\ 

" ‘~‘ a ~ 


9 


20 


25 


24 


27 - 


28 


TOTALS 


499 


621 


692 


728 


736 


755 



‘CSC DEFINITION EXCLUDES CERTAIN PROFESSIONALS IN COMPUTER SCIENCES 



9/30/73 



Figure 2 . 
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totaled over $123 million. Figure 3 shows the history of 
NELC funding by RDT&E categories . ^ 

To . aid in understanding the role played by the lab- 
oratory project manager in equipment acquisition, this • 
chapter presents the NELC organization, manager roles, con- 
flicts and interfaces . 

B. ORGANIZATION 

The traditional method of organizing has been functional 
departmentalization. This method utilizes a top-to-bottom 
model with departments such as engineering, administrative 
support, etc. responsible to one manager. However, if the 
emphasis in an organization is on contract work where the 
workload is composed of various projects with specific ob- 
jectives and well-defined points of completion, then pro- 

30 

ject organization is more appropriate. 

NELC has need for both the functional and the project 
organizational models and therefore operates within a ma- 
trix organization (Figure 4). "The matrix organization 
is the realization of a two-dimensional organization which 
emanates directly from the two dimensions of authority. 

Two complementary organizations — the project organization 
and the functional organization — are merged to. create the 
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Naval Electronics Laboratory Center Digest , prepared 
by NELC Planning Office, 30 June 1973- 

30 

C3 eland. Management , p. 337- 
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HISTORY OF NEIC FUNDING BY RDT&E CATEGORIES 




SNOmitMS 
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TASKED AND FUNDED BY 



EXTERNAL 

SPONSOR 

/ 1000 \ 



EXTERNAL SPONSOR AND NELC . 



NELC 



COMMAND 

CONTROL 

COMMUNI- 

CATIONS 

PROGRAMS 



J 



1100 

SHORE SYS. 

1200 

SURFACE SYS. 

1300 

SUBMARINE SYS. 

1400 

SATELLITE SYS. 

1500 

SECURITY SYS. 

1600 

AIR SYS. 

1700 

MARINE CORPS 
SYSTEMS 






FUNCTIONAL 






RESPONSIBILITIES 






AND AUTHORITY 


mMu 



TASKING 
RESPONSIBILITY 
AND AUTHORITY 



NELC Matrix organization 



Figure *1 . 
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31 

matrix organization." This type organization is ideally 
suited as the NELC operating structure, for NELC is basi- 
cally two dimensional. 

The Command Control and Communications Program Depart- 
ment (Figure 5) contains seven major programs (e.g. Shore 

Systems - 1100, Surface Systems - 1200, etc.) 'which are 

32 

externally sponsored. Each major program in the Command 
Control and Communications Department contains numerous 
smaller projects (e.g. World Wide Military Command Control 
System - 1130 under the Shore Systems Program and the 
Minimum Essential Emergency Communication Network Project - 
1320 under the Submarine Systems Program) which are headed 
by a project manager. The projects within the Command 
Control and Communications Program Department comprise ap- 
proximately one-half of all NELC projects and are tasked 
and funded primarily by the Naval Systems Commands. The 
projects in turn task and fund the five functional depart- 
ments (along with some outside contractors and other labo- 
ratories) for a specific requirement or level of effort. 

The project offices are organized functionally and may con- 
tain only a few code 1000 personnel who are primarily re- 
sponsible for managing the overall project. An example 
of a Command Control and Communications Programs Department 



31 Ibid p. 339- 
32 

For purposes of this paper "externally sponsored" 
refers to any project which is funded directly from a source 
outside the laboratory organization. 
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% 




Figure 5- Command Control and Communications Programs 
Department Organization . 
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project is the World Wide Military Command Control System 
(WWMCCS) project organization depicted in Figure 6. The' 
project organization of the Command Control and Communica- 
tions Programs Department is the first dimension of the 
two-dimensional matrix organization. 

The second dimension of the NELC organization is seen 
in the five functional departments of Electromagnetics 
Technology, Information Technology, Engineering Sciences, 
Computer Sciences and . Administrative and Technical Support. 
Each functional department is further organized into func- 
tional areas of specialization and appropriate staffs 
(Figure 7). The technology and sciences departments main- 
tain some of their own projects which are externally spon- 
sored while at the same time acting as primary support for 
the Command Control and Communications Programs Department 
projects. When a functional department is performing a 
task for a Command Control and Communications Programs 
Department project, a task leader is designated within the 
functional department and has primary responsibility for 
the completion of the required task or level of effort. 

The task leader maintains close contact with the project 
manager through frequent conversations and weekly mile- 
stone/project review meetings. When a functional depart- 
ment has externally sponsored projects, a project manager 
is designated within the department and has control of the 
entire project. 
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Figure 7 • Typical Functional Department Organization 



C. MANAGEMENT ROLES AND THE SYSTEMS APPROACH 



1 . Functional Managers 

The functional manager and project manager have 
different views of the organization. The functional man- 
ager is primarily responsible for a particular function or 
technology within the organization and for providing in- 
formation and skills on the "state-of-the-art" in his dis- 



cipline. In addition, he must support projects in the 
organization which require his knowledge and skill. How- 
ever, he is not responsible to the project office for per- 
formance but is responsible through the chain of command 
for his particular department or subsystem within his de- 
partment. Consequently, it is natural for him to become 
parochial in his viewpoint. If not carried to an extreme, 
this is a desirable situation for it tends to protect the 
integrity of existing specialized areas. The functional 
manager may however, become so wrapped up in his own area 



of specialization that he comes to consider his function 

as the only important one — at the expense of other parts 

of the organization or overall organizational objectives. 

In the very human desire to do a good job, 
the functional manager tends to develop 
"tunnel vision," which allows him to see 
things only within the narrow scope of his 
function and to conveniently ignore the 
"bigger picture" .. .An often-heard gripe in 
a variety of different organizations is that 
the organization seems to be run for the 
benefit of the accounting department or the 
elevator operators rather than to enhance 
the opportunity to achieve overall objec- 
tives . This is a natural out-growth of 
over-zealous functional .management . Since 
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the responsibilities of the functional man- 
ager are limited to his area, he seeks to 
make that area as efficient and effective 
as possible — often without regard to the 
effect of his actions on other functions or, 
more importantly, on the basic tasks which 
the overall organization must perform. 33 

Although this loss of the "big picture" or not using the 
systems approach may become a problem in functional depart- 
ment management, it is not as critical a situation for the 
functional manager as it is for the project manager. 

2 . Project Managers 

The project manager is truly a general manager. He 
must have the "big picture" and view his project and the 
organization in a perspective which will allow him to con- 
sider the performance, cost and schedule aspects of his 
project. At the same time he must motivate diverse groups 
toward a common goal or objective for his project while 
keeping in mind the goals of the total system. Although 
the project manager normally operates at a relatively low 
level in the NELC organization (i.e.. fifth level below the 
Technical Director) "he must perform the same general 
management functions as do top managers — he must integrate 
the efforts of a variety of functional managers to accom- 

3*j 

plish the goals of the project and the organization." 

He must have a basic understanding of all the functional 



■^Cleland, Management , pp . 3^0-3*11. 
^Ibid., p. 3^2. 
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areas and realize the importance of each in the accomplish- 
ment of overall objectives. If he gets "tunnel vision" and 
the attitude that all other projects and functions are less 
important than his own, he may be in a position to upgrade 
his project at the expense of others and possibly at the 
expense of the total system. The project manager must use 
the systems approach. 

D. MANAGEMENT CONFLICT 

Conflict between the functional manager and the project 
manager is a natural outgrowth of the matrix organization. 
The project and functional managers maintain a relationship 
similar to a buyer/seller relationship with their respec- 
tive organizational elements having conflicting objectives. 
The project manager's first objective is to obtain satis- 
factory performance and schedule at the lowest possible 
cost to the project. The functional manager naturally 
wants what is best for his particular subsystem within the 
organization and must divide his resources among various 
projects. "The project and functional managers are thereby 
involved in a deliberate and purposeful conflict within the 
organization . " 

If both managers use the systems approach or think in 
terms of the total system, this conflict is beneficial to 
the objectives of the organization as a whole. The project 
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and functional manager must understand each others problems , 
constraints, goals and objectives in order to maintain an 
atmosphere of cooperation and compromise. If however, the 
manager views his subsystems as the only important one and 
always works to optimize its objectives, conflicts will in- 
crease and may need to be resolved at a common supervisor 
level in the organization. For example, at NELC if the 
WWMCCS Project Manager and a functional manager in the Ap- 
plication Software Division of the Computer Sciences De- 
partment could not reach agreement as to which engineer was 
to be assigned to work on the WWMCCS Project, theoretically, 
the lowest common supervisor at which the conflict could be 
resolved would be the Technical Director (Figure 8). In 
practice, this would probably not happen for the conflict 
would be resolved at a lower level (i.e. the project man- 
ager's superior and the functional manager's superior might 
discuss the problem, make a decision and pass it down to 
the project and functional managers .without allowing the 
conflict to go any higher in the organization) . 

Other conflicts arise involving promotion of personnel, 
personnel tasking, resource allocation and priorities. When 
these conflicts develop, a willingness on the part of the 
functional and project managers to negotiate is essential 
to the proper functioning of the matrix organization. These 
problems are further developed in Chapter IV. 
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Figure 8. NELC Organization 



E. INTERFACES 



1 . External Interfaces 

The range of external interfaces which are re- 
quired by NELC in day to day operations is much too wide and 
varied to investigate in detail. However, some interfaces 
which are the most pertinent to NELC project managers will 
be presented. 

The most important external interface for NELC and 
individual project managers are with Naval Systems Commands. 
Systems Commands (e.g. NAVELEX, NAVSHIPS, NAVAIR, etc.) 
sponsor projects which are the primary source of funds for 
NELC operations. There are many formal and informal inter- 
faces with the Systems Commands which are carried on in 
various ways. For example, the WWMCCS Project Office in 
the Command Control and Communications Programs Department 
was established when NAVELEX informed NELC of their require- 
ment through a task statement. A rough estimate of the task 
cost and schedule was prepared by NELC. NAVELEX then di- 
rected NELC to prepare a task summary which included items 
such as a task description, a funding summary, subtask 
descriptions. Quality Assurance requirements. Integrated 
Logistic Support considerations, test and evaluation re- 
quirements, etc. NAVELEX and NELC then negotiated cost, 
schedule and performance requirements prior to NAVELEX ac- 
ceptance of the NELC prepared task summary. Once the task 
summary was accepted, it was comparable to a contract be- 
tween NAVELEX and NELC. 



In the initial phases of project establishment 
just described, there are many NELC and sponsor personnel 
and disciplines involved in the planning interface between 
NELC and the sponsor. Once the project is established 
there is one individual as the primary point of contact in 
the Systems Command that interfaces with the NELC project 
manager, but the project manager frequently must deal with 
other sponsor personnel in areas such as funding. Integrated 
Logistic Support, etc. 

Not all NELC projects are sponsored in the Naval 
Systems Commands (Figure 9) • Approximately one quarter of 
NELC projects are sponsored by other sources such as the 
Director of Laboratory Programs, the Marine Corps, other 
Navy sources, other Department of Defense sources and other 
government sources (Figure 10 contains examples of non-Navy 
sponsored programs in fiscal 73) • Each of these projects 
requires the same basic interfaces as Systems Command spon- 
sored projects. 

Another important external interface for NELC pro- 
ject managers is in the area of commercial contractor sup- 
port. One of the primary sources of project support comes 
from external sources (e.g. the MEECN Project relied upon 
contractor support for approximately twenty-five percent 
of its tasks). If a project requires support in a particu- 
lar area which is not available from a NELC functional de- 
partment or can be .obtained at a better cost and schedule 
from a contractor, the project manager may develop a 
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NON-NAVY PROGRAMS (30 JUNE 73) 
GOVERNMENT 



PROBLEM 



SPONSOR 


TITLE 


NUMBER 


FY 73 FUNDS (SK) 


Air Force 


Solar Telescope Image 


M206 


50 






Fiber Optics Radiation Effects 


F218 


50 






Airborne VLF Propagation 


M2 15 


50 


. 




Advanced Anti-Radiation 


H101 


56 






Short Pulse Backscatter 


D21 1 


50 






Detector Evaluation 


T301 


50 






Hydrus 


B218 


25 






Emissivity Evaluation 


T302 


5 












336 


Army 


Detector Evaluation 


T301 


200 






P1DEP 


F209 


75 






RF Signature Sensor 


F108 


62 






Surveillance with UV 


K285 


10 






Advanced Anti-Radiation Sensor 


H101 


2 






ADP Services 


K337 


20 












369 


ARPA (OSD) 


Develop and Improve Ribbon Wiring 


R215 


100 






Fiber Optics Evaluation 


T304 


62 






Detector Evaluation 


T301 


100 






Transmittance Measurement 


T302- ' 


50 






Integrated Optics Circuits Technique 


F215 


370 






Remote Sensor 


D308 


92 




- 


Blue-Green Dye Laser 


B403 


60 












834 


DCA 


Scintillation Effects on SATCOM 


M405 


50 






VLF/LF Propagation 


M216 


100 






DCA Data Compressor 


R304 


120 












270 


DNA 


Ionospheric VLF-ELF Propagation 


. M402 


127 






Atmospheric Dynamics in Ionosphere 


M2 13 


25 






VLF-ELF Nuclear Weapon Effects 


M20S 


175 












327 


FAA 


FAA-VLF Handbook 


A206* 


15 






Automatic Monitoring 


R136* 


250 












265 


NASA 


Solar Contour Mapping 


M2 14 


25 












25 


U.S. Coast Guard 


Antenna Improvement 


B169 


18 






Omega 


A 107/1 10 


262 












280 


U.S. Postal Service 


Remote Video Encoding 


N451* 


100 






Facts Visibility System 


K347 


60 





160 
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Figure 10 . 



PROBLEM 



SPONSOR 


TITLE 


NUMBER 


FY73 FUNDS ($K) 


APLJohns Hopkins 


HF Sounder 


M212 


30 








30 


Bureau of Standards 


Fabricate Field Sensor 


K273* 


6 

6 




Total Government 




' 2,902.0 




. NON-GOVERNMENT 




AETL 


Shock Test 


K288 


3 


Cubic 


Shock and Indication Test 


K287 


1 


Langley Corp 


Vibration Test 


K258 


15.1 


Motorola 


Drop Hammer Shock Test 


K269 


0.7 


RCA 


Shock Test/RF Amp 


K278 


1.2 


Science Application Inc 


Computer Rental 


K330 


0.5 


Sonetronics 


Inspection/Testing 


T271 


0.4 


Dynal 


Inspection/Testing 


T271 


1.0 


U.C. Scripps 


Support 


K408/523/ 


47.0 






909/218 




Chu Assoc 


Testing 


K216 


18.3 


Umv of V/ ash 


FORACS-SACS 


R112 


95.0 




Total Non-Government 




183.2 




Total Non-Navy Programs 




3.0S5.2 



Figure 10. Continued. 
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relationship with a commercial contractor in order to ‘obtain 
the necessary support for his project. In addition, the 
Administration and Technical Support Department, through 
the Supply and Contract Services Division, will interface 
with the Navy Regional Procurement Office, Long Beach in 

q /T 

contracting for the required support. This interface is 
further discussed in Chapter IV. 

The "fleet" is another external interface with which 
NELC must maintain close contact. As the user of NELC de- 
veloped equipment, the fleet necessarily provides inputs to 
project offices. These are sometimes direct inputs to the 
project office through a fleet liaison staff and are some 
times indirect inputs through the Systems Command sponsor. 
For example, the WWMCCS project organization contains a 
Fleet Liaison Staff which maintains direct contact with 
fleet units concerned with the project. Another example of 
a fleet interface is the test and evaluation of laboratory 
developed prototypes conducted in operational commands by 
laboratory personnel. 

The Naval laboratory and the projects within it 
maintain many other external interfaces which have varying 
degrees of importance to the organization. A few examples 
include: professional meetings in technical areas, seminars 



^ NELC has purchase authority of $2,500 for routine 
requirements and $10,000 for emergencies. Any requirement 
which exceeds these thresholds must go through NRPO Long 
Beach . 



with industry, management consultant groups, educational 
institutions and other laboratories . 

2 . Internal Interfaces 

The NELC matrix organization chart indicates that 
the project manager must maintain many internal interfaces 
throughout the system. His primary interface with the 
technical functional departments is with the task leader 
who is assigned in the functional department to work on a 
given task for his project. In the personnel area, the 
project manager has little direct influence as to the choice 
of individuals assigned to his project within a functional 
department (i.e. the functional division head knows his 
personnel, what type project each is best suited for, man- 
ages his resources to support many projects and is the line 
authority for functional task leaders). However, the pro- 
ject manager will sometimes "politic" to influence the 
assignment of a certain key individual when he has definite 
feelings that the individual and task are well matched. 

The project manager must also work closely with 
Administrative and Technical Support Department personnel, 
particularly in the Supply and Contract Services Division. 

If his project requires support from commercial contractors, 
the project manager must maintain a close relationship with 
contract specialists in the Supply and Contract Services 
Division to ensure that the required items in the procure- 
ment package (Figure 11) are properly prepared and sufficient 
lead time is allowed to prevent project schedule slippages. 
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Figure 11. '' NELC PROCUREMENT CYCLE PLOW CHART 
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Many projects interface directly with the staffs 



which come under the Deputy Technical Director (Figure 8). 
These staffs include such areas as systems analysis. Quality 
Assurance, advanced technologies and planning; and are used 
to varying degrees by different projects. For example, the 
WWMCCS Project Office utilizes analysis personnel (Code 230) 
as integral parts of its organization. 

Finally, an important internal interface which must 
be maintained in any organization is the line authority 
chain of command within each department. The project man- 
ager is working for two bosses, his project sponsor and his 
superior in the department chain of command. The interface 
with his chain of command superior concerns the areas of 
internal procedures, personnel assignments, reports and any 
dealings up or down the chain of command. However, the 
fact that the project manager often feels obligated to sat- 
isfy his project sponsor first and his department superior 
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second, is a good example of the "gplden rule" in project 
management . 
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The man with the gold makes the rules. 
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IV. THE PROJECT MANAGER IN THE SYSTEM 



A. INTRODUCTION 

A project manager and a project sponsor were on a hunt- 
ing trip. One morning the sponsor woke up early and went 
into the brush to get a lead on a bear which was reported 
to be in the area. The project manager was about to join 
him companion when he heard two shots and a blood chilling 
roar. His friend came running toward the tent yelling, 

"Open the flap! Open the flap!" Just as the project man- 
ager opened the flap, the sponsor ran into the tent chased 
by a huge bear not twenty yards behind him. As the sponsor 
ran through the tent and out the back he shouted, "You take 
care of this one while I bring in another one!" 

This chapter is concerned primarily with the man in the 
tent, the project manager. The problems which confront the 
project manager in the Naval laboratory are many and varied. 
In the previous chapter some general problems and inter- 
faces with which he must contend were discussed. In this 
chapter the history of project management, NELC project 
manager's profile, planning and control problems and use of 
the systems approach will be discussed. The problems and 
techniques presented are generally applicable to project 
managers in a matrix organization regardless of size or 
type of project. Many problems which are discussed were 
contributed by the project managers who were interviewed and 
some are inherent in a matrix organization. The project 
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managers and associated personnel interviewed are not quoted 
directly, but some of the thoughts and words used are para- 
phrases and composites of the remarks of several. 

B. HISTORY OP PROJECT MANAGEMENT 

The origin of project management can be traced to World 
War II and the Manhattan Project in 19^2.^ The concept of 
project management has evolved and changed over a number of 
years and may have been called by different titles in ear- 
lier usage. The technique of project management today is 
viewed in the Department of Defense as a means to deal with 
the problems experienced in the acquisition of weapon 
systems . 

The prime mover in the evolution of project management 
was the technological revolution which made possible the 
complex systems of today. The technology which initiated 
the Manhattan Project was the nuclear physics of Albert 
Einstein. Although the Manhattan Project had an extremely 
high wartime priority, success may not have come so rapidly 
(project initiation to first bomb in three years) without 
the use of good project management techniques. 

In addition to the Manhattan Project, defense require- 
ments for large quantities of complex systems forced indus- 
try to look for new ways to manage development and production. 

q D 

JO The Manhattan Project was the effort to develop the 
first atomic bomb. ' 
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Difficulties involved in obtaining new weapons in a reduced 
amount of time created difficult management-type problems. 
Industry looked to project management as one possible 
solution . 

The military services have used some form of project 
management techniques since the mid-1950's. The Air Force 
created the Ballistic Missle Division with the responsi- 
bility of managing the Atlas, Thor and Titan programs; the 
Navy organized the Special Projects Office for management 
and development of the Polaris missle; and the Army es- 
tablished the Army Ballistic Missle Agency to develop the 
Jupiter missle. Each of these organizations had similar- 
ities that indicated a need for special management tech- 
niques. Each program was given high priority within the 
services and had first choice of personnel, authority over 
support organizations, exemption from normal procurement 
procedures, access to top officials and special funding. 

A project manager was selected and provided with special 
authority over personnel, materials, facilities and funds. 
These were important projects and contributed significantly 
to the evolution of project management in the military. 

By 1961 the techniques of project management had been 
applied to many acquisitions other than missies within the 
services. However, there was a wide range of policies and 
procedures used from one service to the next and within 
each service. A task force was formed to study acquisition 
methods throughout the services with emphasis on project 
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management techniques. The result of the study was a set 
of recommendations which included: more extensive use of 

project management techniques as found in the Air Force and 
Navy, use of Program Evaluation and Review Technique (PERT) 
should be encouraged, more work should be done in the area 
of delegation of powers to project managers and all services 
should employ a common management technique for use in 
acquiring complex weapon systems. 

Interest in project management continued to increase 
throughout the 1960's with conferences, studies and courses 
on project management techniques in the Department of 
Defense. In May, 1965 j DoD Directive 5010.4, "System/Pro- 
ject Management" attempted to pull the services together in 
their efforts to manage projects. The Directive was intended 
for major designated projects and covered mandatory and 
nonmandatory application of project management techniques 
and procedures. Major system acquisition in the Department 
of Defense has continued to require. the use of a chartered 
project manager and project management techniques. 

In recent years, the project management concept has 
been applied to many other functions where there is a spe- 
cific objective which, when achieved, means the end of the 
function. Project management today is widely used in in- 
dustry where a specific product must be developed and many 
functional lines must be crossed in its development. In- 
dustrial project management developed along the same lines 
as the Department of Defense project management. Technological 



advances with the accompaning need to concentrate respon- 
sibilities for development and production effort in one 
organization were the primary factors responsible for its 
adoption . 

The application of project management techniques to the 
Naval laboratory is a direct result of the successes achieved 
on other government and industrial projects. The advantages 
of project management techniques for equipment development 
are obvious when applied to organizations where the emphasis 
is on projects with specific objectives and well-defined 
points of completion (as in the Naval laboratory develop- 
ment project). In recent years, the use of project managers 
and project management techniques has proven to be an ef- 
fective management concept. 

C. NELC PROJECT MANAGER PROFILE 

The laboratory project manager is a key individual in 
a process which is meant to provide for more economical and 
effective acquisition of equipment having the required per- 
formance and operational availability which can be sustained 
in a designated military environment. As a key individual 
in the development project, his responsibilities cover many 
areas and he should have a versatile background in adminis- 
trative areas associated with engineering as well as in 
engineering technology. 

From the interviews and research conducted at NELC, a 
"typical" laboratory project manager profile can be developed. 
He is forty-five years of age, has-been with the laboratory 
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for eight years, has a degree in electrical engineering and 
has had experience in his field prior to coming to the lab- 
oratory. This profile does not fit any particular individ- 
ual, but is an aggregate of the backgrounds of a sample of 
twelve NELC project managers (Figure 12) . This "typical" 
profile reflects the Naval Electronics Laboratory Center 
orientation with the project manager's educational back- 
ground in electrical engineering, his main field of activity 
In addition, from the twelve profiles available to the 
authors, it is clear that a basic premise of Chapter I is 
supported in that only two (E and K in Figure 12) appear to 
have any management training in their background. Also, 
two of the twelve project managers in the sample hold ad- 
vanced technical degrees. 

However, any specific project managers background will 
vary and his opinions as to what is most important in his 
background will vary greatly from project manager to pro- 
ject manager, depending on how he views his function. One 
project manager interviewed had obtained his undergraduate 
degree in electrical engineering/physics and his masters 
degree in management. He considered the management degree 
as the most important to the management function which he 
performed. In other words, he viewed his job as that of a 
manager and considered the management education, experience 
and techniques which he possessed as being the most useful 
in accomplishing his project objectives. On the other hand, 
another project manager with a degree in electrical engineer 1 
ing and a minor in business administration considered the 
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PROJECT MANAGER PROFILES 



(Sample of 12 NELC P.M.'s) 





PROJECT 

MANAGER 


AGE 


EDUCATION 


WORK EXPERIENCE 
LAST TEN YEARS 


YRS AS 

P.M. 


YRS AT 
NELC 




A 


" 46 


B. S. 

ElctEng 


NOL Corona 
NELC 


12.0 


3.2 


J 


B 


38 


M. S , 

Computer 


NASA & NELC 


4.0 


5.8 




C 


41 


B. S. 
Physics 


Ryan & NELC 


4.0 


9.7 


-1 


D 


49 


B. S. 

ElctEng 


London 

NELC 


7.3 


’-11,7 


* m 


E 


50 


' B. S. 
BusMgmt 


Navy & NELC 


7,4 


7.4 


' 


F 


35 


B. S. 

ElctEng 


Aeronutronic 

NELC 


5.1 


5.1 


> 


G 


38 


M. S. 

TP “1 


Andrews AFB 
NELC 


3.4 


3.4 




H 


35 


B. S. 

Math 


NELC 


4.0 


5.8 




I 


36 


B. S. 

ElctEng 


Assoc. Aero Sci. 
Labs & NELC 


4. 0 


9.4 




J. 


31 


B. S. 

' ElctEng 


NSRF, Guam 
NELC ■ 


5.0 


13.0 




K 


44 


B.E./B.B.A. 

ElctEng 


NUV/C , TAA 
NELC 


5.9 


5-9 


- 


L 


50 


M. S. 

ElctEng 


NELC 


12.0 


22.8 



Figure 12. 
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management portion of his education as unimportant. He 
viewed his job as that of a developmental engineer. He 
felt he hadn't used the management portion of his education 
in his past experience and most of the formal management 
procedures learned had been forgotten. He believed that 
management training would be of value in managing his pro- 
ject but that he was too busy dealing with pressing prob- 
lems to take advantage of any formal management training 
which was available. 

It was obvious to the authors that the manner in which 
the two project managers tracked their projects reflected 
their feelings on the importance of a management orienta- 
tion. There seemed to be organized, orderly procedures 
for project control in the first, while the second was a 
"put out the fire" approach. However, both project mana- 
gers were managing projects which appeared to be successful 
in that they were making progress toward the development 
of a desired system and kept their sponsor well enough 
satisfied to continue supplying funds. In addition, both 
had been laboratory project managers before assignment to 
their current projects. This tends to support a statement 
from an earlier interview that a NELC project manager re- 
mains in project mangement if he "gets the job done." 

The ability to do whatever is necessary to "get the 
job done" is probably the single most important trait in a 
project managers makeup. He must be able to make decisions 
which are necessary to accomplish project objectives. 
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Formal mangement education can be an Invaluable part of the 
project manager’s background to aid him in making the right 
decisions, but is not essential. Experience gained on prior 
projects or assignments and individual judgement, common 
sense and an intuitive feel for making the right decision 
can enable the project manager to successfully control his 
project. The ability to plan, organize, control and com- 
municate is essential to getting the job done in any project 
and every project manager accomplishes these functions one 
way or another, with or without formal procedures. He may 
not view himself as a manager but he is at the focal point 
of every major problem area of his .project. His ability to 
handle these problems (which will be discussed in the next 
section) has a direct bearing on whether his project is 
successful, partially successful or cancelled. The problem 
areas referred to are management problems and are problems 
which tend to recur frequently. There is no intention here 
to imply that technical problems are less severe; they may 
in fact be the toughest ones to solve, but they are general- 
ly unique. The recurring problem areas are management prob- 
lems and require a management ability (whether formal 
education or experience in the project manager's background) 
in order to arrive at workable solutions. 

D. PLANNING, CONTROLLING AND THE SYSTEMS APPROACH 

The problem area concerned with planning has a major ef- 
fect on management problems within a project. Most problems 
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which develop in a project can be traced to poor planning 
in the earlier stages. All other project functions depend 
on planning, deciding what to do, when to do it and where 
to do it. The project manager must plan for scheduling, 
budgeting, contingencies, personnel, reports, etc. and use 
the systems concept of planning which requires looking at 
the organization as an integration of all of its parts. n 

Many problems associated with project management can be 
reduced or eliminated with good planning early in the pro- 
ject's life. 

The primary results of faulty, unrealistic or incom- 
plete planning is loss of control over many aspects of the 
project which can eventually result in complete loss of the 
project. This should be incentive enough for any project 
manager to do his utmost to ensure that adequate planning 
for his project is accomplished. This planning should be- 
gin in the project proposal stage with the sponsor's task 
statement and continue throughout the life of the project. 
The early planning should include project organizational 
structure, schedules, manpower requirements, in-house and 
contractor efforts, funding requirements, etc. This initial 
planning effort is the key to a successful project with a 
minimum of problems. It is a guideline for normal project 
operations and is a baseline to fall back on in meeting 
unexpected changes and crises. 

Planning techniques which may be used by a project man- 
ager vary in complexity and usefulness, depending on the 
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size and complexity of the project. A small single func- 
tion project may require a relatively simple plan and plan- 
ning technique while a large complex multifunction project 
may require many planning techniques and documents to pro- 
vide adequate direction. However, all projects should have 
a written plan covering what is to be done, how, when, by 
whom, what it will cost, major foreseeable problems and 
possible solutions. 

A detailed explanation of planning techniques which are 
useful to the project manager is beyond the scope of this 
paper. Some general techniques which project managers have 
found to be useful in project planning and which develop 
into project control tools as the project progresses include 

• a cumulative expenditure budget which plots time 
versus expenditures j 

• a rate of expenditures budget which plots time 
versus expenditure rate; 

• bar charts with project milestones; 

• networks and the critical path; 

• work breakdown structures which can set the stage 
for all subsequent planning; 

• make or buy analysis ; and 

• PERT, which is an excellent planning device because 
it details the sequence of steps necessary to pro- 
ject completion based on their relation to each 
other . 

Some illustrations and discussion of these techniques can 
be seen in Appendix A. 

Planning is one of the initial problems the project 
manager must face and it is not an' easy task. However, if 
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he realizes that thorough, complete, well thought out plans 
will help to avoid many of the problems which may develop 
in the future, planning should become easier. The project 
manager’s attitude toward planning is reflected in his pro- 
ject organization and the control which he maintains over 
his project. In the examples of two project managers cited 
earlier, one viewed his job as that of a manager and his 
management orientation was reflected in thorough, detailed 
project planning, while the other viewed his job as that of 
a developmental engineer with little emphasis on management 
and his project did not appear to contain any plan to assure 
that the project progressed toward its end objectives. For 
example, the second project was in the advanced development 
stage and there was no plan for reliability requirements. 
Quality Assurance or Integrated Logistic Support nor were 
milestones which had been developed in planning closely 
monitored. In fact, the project manager stated that mile- 
stone reports (i.e. keeping track of milestones made and 
missed) were not used, were not helpful in project control 
and were only prepared because it was a requirement. Addi- 
tionally, there appeared to be no real control system used 
to track project progress (i.e. PERT, Gantt charts, mile- 
stones, graphs , etc.). There seemed to be a general feel- 
ing that paperwork/reports might be of some value but there 
wasn’t time enough to prepare and use them. Lack of admin- 
istrative support was cited as one reason that the project 
appeared to be a generally "off the cuff" operation. It 
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appeared to the authors that with some additional planning 
and budget control the project might find funds available 
to hire enough administrative support to allow the proper 
use of project control techniques. For example, it ap- 
peared that the only fund controlling and monitoring tech- 
nique used was a weekly computer printout which presented 
the amount each functional code had expended on the project 
the previous week. 

In contrast, the first project contained detailed net- 
works with milestones from project initiation to completion, 
all responsible personnel were identified, there was a com- 
prehensive Integrated Logistic Support plan and Quality 
Assurance plan and complete budgeted expenditures were laid 
out. In short, where the project was ultimately headed, 
where it had been and where it would be at any point in the 
future was very clear. In the opinion of the authors, this 
type of detailed planning can make the project manager’s 
job much easier, solve many problems as they arise and 
give the project a much greater chance for success. 

Another problem area for the project manager is in con- 
trolling his project's day to day operations. The primary 
elements concerned with project control are budgets, costs, 
schedules and progress. If a project manager can maintain 
control of these four elements he can maintain control of 
his project. Costs and progress refer to actual costs and 
progress while budgets and schedules refer to planned costs 
and progress. The project manager must be able to track actual 
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versus planned in order to know when significant deviations 
occur and take action to correct the deficiency. 

Various methods were used by laboratory project managers 
to maintain control of costs and progress. One of the bet- 
ter systems was based on the use of milestones and mile- 
stone reports . The milestone report was an important tool 
for the project manager in controlling his project and 
could be prepared in various ways. The project manager 
might receive an input from each responsible task leader, 
prepare the milestone report and distribute it. Using this 
method does not necessarily obtain the fullest cooperation 
from task leaders and functional managers because they 
might interpret the report as only reflecting the project 
manager’s viewpoint and biases and feel that the milestone 
report did not reflect their problems or the real reason 
a milestone was missed. 

The World Wide Military Command Control System Project 
Office appeared to the authors to have an excellent method 
of implementing their milestone and milestone report control 
system which encompassed the systems concept philosophy. 

The WWMCCS Project Manager felt that one of his prime func- 
tions was to obtain the cooperation, understanding and full 
support of functional personnel for his project. Therefore, 
he prepared a detailed milestone report on a weekly basis 
which was a function of a Monday milestone/project review 
meeting. This meeting was attended by project personnel 
and all functional task leaders assigned to accomplish 
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project tasks. If a milestone had been missed in the pre- 
vious week or was expected to be missed in the near future, 
it was discussed with the responsible task leader, the re- 
port was prepared and was eventually reviewed at the depart- 
ment head level. Since one of the prime objectives of the 
project manager was to obtain and present a clear and total 
picture of his project's progress and schedule, the con- 
tents of every milestone report was prepared with the co- 
operation and agreement of the responsible task leader and 
his input was the most important part of the report. 

In addition to milestones, the WWMCCS Project Office 
prepared a monthly management control document for use as a 
project control tool. Again, the most important input came 
from the functional departments and gave the project manager 
a more accurate overall view and better understanding of his 
project and the organization. This document contained net- 
works with milestones for each task leader, cumulative mile- 
stones met and missed to date with an explanation of any 
missed and a plot of budgeted versus actual costs to date. 
The explanation of missed milestones included an estimate 
of its probable effect on the project as a whole and a new 
expected completion date for the milestone. 

Another weekly meeting was used for the project configu- 
ration management program and included a review of detailed 
engineering change requests, engineering change orders and 
field engineering change reports. The day to day tools 
used by the project manager to control his project included 
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graphs, Gantt charts and networks. An example is the fi- 
nancial status chart which is strictly a project manager's 
tool and tracks budgeted versus actual expenditures (Ap- 
pendix A contains examples of project control tools, some 
of which were used in the WWMCCS Project Office). 

There was also frequent contact with task leaders, con- 
tractors and the sponsor through telephone calls and meet- 
ings. The project manager felt that the management tools 
which he used were essential if he was to maintain adequate 
control of his project and a clear understanding of the 
problems and relationships which affected it throughout the 
organization . 

Whatever management control techniques the project man- 
ager uses, they must tell him what progress (in both sched- 
ule and performance) he is getting for the money he is 
expending, give him enough detail on trouble areas so that 
he can take the required action, and enable him to see up- 
coming problems. To know where, when, why and what kind of 
action to take, the project manager must be able to track 
his project cost, schedule and performance. He must simul- 
taneously consider all these elements of his project and 
their effect on each other. How well he does this deter- 
mines the effectiveness of his management — whether he will 
control the project or be controlled by the project. 

A major problem area which created much concern within 
every project office and for each project manager inter- 
viewed was budget cuts. The project manager has little 
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control of budget cuts from his project sponsor and there 
seems to be no optimum way to plan for or predict cuts in 
total funds. Planning for contingencies can include a plan 
for certain cuts in particular areas to aid in the accom- 
panying reduction of effort, and the project manager should 
have priorities set up from the most to least critical 
areas in his project. When a budget cut comes from the 
sponsor, there are basically three methods a project man- 
ager can use to reduce the funds to the functional depart- 
ments. He can eliminate the lowest priority tasks if he 
has planned with priorities in mind and the nature of his 
project allows it. He can reduce the level of effort on 
each task by a set percentage and settle for reduced per- 
formance and a less desirable schedule. Finally, he can 
try to reduce the funds to the functional departments so as 
to have the least impact on his project while at the same 
time considering the current situation in each functional 
department (manpower utilization, current need for funds, 
etc.) and make cuts that have the least effect on the en- 
tire organization. Again, to do this he must have planned 
with priorities in mind so he knows where he can accept 
less performance. 

As indicated in Chapter II, the authors consider the 
systems approach as primarily a management philosophy or 
way of thinking which a project manager can use as a frame- 
work to visualize the system in which he operates and how 
his project or area of responsibility is constrained and 
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influenced. The systems concept can make the job of man- 
aging a project easier by giving a better understanding of 
the system, but it can also make some decisions more dif- 
ficult be requiring the consideration of more variables 
(e.g. the decision to use in-house effort rather than an 
outside contract for the development of a particular module 
might be easily made if the only variable considered is 
initial cos t ) . 

The systems approach can be applied when considering 
the method used by a project manager in distributing funds. 
If the project manager is always thinking of his project 
alone and always makes decisions in the light of their im- 
mediate effect on his project, he may attempt to use com- 
mercial contractors to a maximum extent in order to obligate 
as much of his budget as possible to guard against budget 
cuts (i.e. funds within the laboratory are easily recalled 
by a sponsor while funds obligated in a contract are not). 
This method of handling funds may reduce the difficulty of 
a future project decision when a budget cut comes, but it 
may also cause problems in the overall system. The func- 
tional departments are partially dependent on the Command 
Control and Communications Programs Department as a source 
of funds. If the functional departments are not utilized 
whenever possible by project managers, in the long-run the 
total system may suffer. 

Most successful project managers employ the systems ap- 
proach to project management whether they realize it or not. 
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In the example on budget cuts, one project manager inter- 
viewed used the systems approach in the decision-making 
process concerning redistribution of funds to the function- 
al areas involved in his project. After receiving a budget 
cut from his sponsor, the project manager would first look 
at areas which were least critical to the project as pri- 
mary candidates for the major portion of the fund reduction 
At the same time however, he would look at the present and 
possible future situation in the particular functional de- 
partments concerned. Factors such as the workload in the 
department, its present need for funds and its ability to 
transfer personnel to other projects might be considered or 
might be factors which eventually tip the scales in favor 
of a greater fund reduction in one functional area versus 
another . 

A project manager must know the organization in which 
he operates. He should know how each subsystem within the 
total system functions and their relationship to each other 
in order to understand the overall effects his decisions 
will have. An example of using the systems approach or con 
sidering other subsystems in the organization when making 
project decisions is in the area of contracting. The labo- 
ratory project manager must understand the procurement pro- 
cess and exactly what is involved in government contracting 
with commercial sources. The Supply and Contract Services 
Division within the . Administrative and Technical Support 
Department performs a very important function for the pro- 
ject manager when he must utilize a commercial contractor 
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to perform a certain task or level of effort. The contract 
specialists are in the organization to facilitate the NELC 
procurement cycle (Figure 11) and act as an interface between 
the project manager and the Navy Regional Procurement Office 
(NRPO). A primary part of the procurement cycle and one 
which must be understood by the project manager is the pro- 
curement leadtime (Figure 13)- If the project manager is 
aware of the procurement requirements and procedures which 
must be accomplished prior to contract award, makes an at- 
tempt to bring the contracting specialists into the prepara- 
tion of the procurement package as early as possible and 
understands the constraints which face anyone involved in 
government procurement, he will not only be increasing the 
probability cf having a successful project but will be 
helping the total system to meet its objectives. 

A project manager cannot sit in his office, make his 
plans and control his project without understanding the 
requirements of other subsystems. For example, a project 
manager may have planned for many months to procure a 
particular piece of equipment which he needs on a certain 
date to meet his schedule. Without really understanding 
the leadtime involved in the procurement, he prepares the 
procurement package and it arrives on the contract special- 
ist's desk with a notation to the effect that the item 
"must be in the project office within thirty days or the 
schedule is shot." If the procurement requires competition 
according to the Armed Services Procurement Regulations, 
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The following indicates average number of days elapsed 
between the time the purchasing office receives a complete 
procurement package to contract award. 



Calendar days 



a. Requirements to be negotiated with 210 

an estimated cost in excess of 

$ 2 , 000,000 

b. Requirements to be negotiated with 160 

an estimated cost between $300,000 

and $2,000,000 

c. Requirements to be negotiated with 1^3 

an estimated cost between $100,000 

and $300,000 

d. Requirements to be negotiated with 91 

an estimated cost between $10,000 

and $100,000 

e. Requirements to be formally adver- 120 

tised in excess of $10,000 

f. All other requirements, exclusive 6 0 

of Installment Funding 

g. Amendments involving exclusively 20 

the addition of funds in accordance 

with an existing Installment Funding 
Clause 



Figure 13. Procurement Leadtimes. 
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the leadtime required just to get the contract signed may 
be ninety days or more. If the need is urgent enough and 
another procurement method can be justified, the contract- 
ing division may be able, through extra effort and some 
kind of "firedrill," to reduce the leadtime and meet the 
project's schedule. If the project manager had understood 
the effort involved, he may have brought the contracting 
specialist in much earlier and been able to prevent many 
headaches for himself and others. Looking at his organiza- 
tion as a system made up of subsystems which affect each 
other, the project manager can reduce many of his problems 
and total system problems. 

A final example of the systems approach in laboratory 
project management is in the area of personnel. A project 
manager normally has little real influence on the selection 
of which individuals will be assigned to his project from 
the functional departments, but can sometimes "politic" to 
influence the assignment of a certain key individual when 
he has strong feelings that the individual and task are well 
matched. This procedure can be beneficial to both the pro- 
ject and the organization as a whole if not carried to an 
extreme. If a particular project manager, because of his 
project's priority or his persuasive ability, is able to 
obtain the best qualified people from each functional de- 
partment with which he deals, his project will be well 
staffed with the best talent but other projects and overall 
organizational effectiveness will suffer. To use the systems 
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approach, the project manager must view manpower management 
as a subsystem interacting with other subsystems in the or- 
ganization. He should develop a personnel program that is 
adaptable to his project and can be directed toward estab- 
lishing and maintaining an adequate and satisfactory pro- 
ject team. He must strive to staff his project with 
personnel who are compatible with the objectives of his pro- 
ject, not necessarily the individuals who appear best 
qualified in every technical area. 

To use the systems approach is not difficult but it 
requires the ability to see beyond the immediate effects 
and advantages of a given decision. It requires the ability 
to see the "big picture" or what is best for the total sys- 
tem in the longrun. It may even require a project manager 
to say "this project is not going anywhere, it's a waste 
of money and should be discontinued" with the full know- 
ledge that if it is dropped, he must find a new project and 
source of funds . 
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V. CONCLUSIONS 



The systems approach to management is a way for the 
manager to view his environment which allows him to make 
more viable decisions. If the laboratory project and 
project manager functioned in a vacuum; if every decision 
affected only the project; then the systems approach would 
not apply to NELC . However, from the very nature of the 
laboratory organizational structure and from the manner in 
which it operates (as described in Chapters III and IV) , it 
is apparent to the authors that the systems approach is the 
most applicable management concept for NELC. 

The systems approach has been applied by some project 
managers (although they may not have called it the systems 
approach) with success. Other management approaches may be 
more successful in some situations over the short-term, but 
the systems approach should provide the most rewarding long- 
term benefits for the laboratory project manager. 

The NELC project manager is normally an engineer or an 
individual with a technical background. This technical 
training is of prime importance to the project manager and 
helps him to deal with the difficult, complicated and some- 
times unsolvable technical problems which are encountered 
in a development project. However, when a developmental 
engineer moves from the laboratory bench to the project 
manager's desk, the recurring problems which he must face 
are management problems. Budgeting, re-budgeting and 
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tracking expenditures for example, are day to day problems 
which are encountered. Failure to effectively plan for and 
control these types of problems can lead to the failure of 
a project just as surely as the inability to solve a major 
technical problem can be a project's downfall. 

Therefore, the laboratory project manager must realize 
that he is more than an engineer. He is also a manager and 
he must develop a management philosophy which will enable 
him to cope with the management problems he faces. The 
management tasks should not be underestimated. Careful 
attention should be paid to the planning process, including 
the identification and analysis of alternatives, and a clear 
cut understanding of the actions and responsibilities of 
supporting personnel both within and outside the Naval 
laboratory. In addition, the project manager must have an 
effective control system that provides timely feedback on 
potential problems and allows him to take corrective action. 

He must have a management orientation or philosophy which 
allows him to see the entire project and all of its 
interfaces . 

In interviews conducted over the six month period, there 
appeared to the authors to be no universal understanding or 
use of the systems approach. However, it was obvious that 
some project managers operated under the systems philosophy 
and thought positively in a managerial sense and that to 
some extent the systems approach was used by everyone inter- 
viewed. In other words, for a project manager to successfully 
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function in an environment such as NELC where frequent contact 
is required with subsystems other than his own, he must be 
able to understand and obtain the cooperation of these sub- 
systems . Otherwise he will not be likely to remain a pro- 
ject manager. Nevertheless, in the opinion of the authors 
he can be a more effective project manager if he is aware 
of the systems concept and attempts to make every decision - 
in the light of its affect on other subsystems and the total 
system . 

The NELC project manager appeared to operate under some 
constraints which may not be common to project managers in 
general. Within his organization he operated as an indi- 
vidual in a chain of command with a supervisor directly 
above who placed demands upon him. He also had to satisfy 
his project sponsor who was external to the organization. 

The fact that he was trying to satisfy two bosses whose ob- 
jectives might not coincide is in conflict with basic prin- 
ciples of any management approach. 'An example was the 
individual who let internal requirements slide so he would 
have time available to satisfy sponsor requirements. In 
his mind, and maybe rightly so, he could not justify the 
time required to deal with all internal demands . This type 
of situation will make it more difficult for the individual 
manager to practice the systems approach (i.e. when the de- 
mands of one interface are seen as all important, the re- 
lationship with others is degraded) . 
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Another constraint with which the NELC project manager 
must deal is in the area of commercial contracts. The pro- 
ject manager in industry normally has complete control of 
his project and can subcontract' tasks when necessary. The 
laboratory project manager on the other hand, has no con- 
tracting authority. In fact, to contract with a commercial 
vendor he must go through two more systems or organizations. 
First, he deals directly with contracting specialists in 
the Supply and Contract Services Division to prepare his 
procurement package. Then the Supply and Contract Services 
Division must interface with the Navy Regional Procurement 
Office which lets the contract. From the viewpoint of the 
project manager this is not an ideal contracting procedure, 
but it illustrates the necessity for the project manager to 
understand systems other than his own, know their constraints 
and procedures and made decisions which affect his project 
with the knowledge of their affect on those systems. 

In preparation of the procurement package and specifica- 
tion writing, there appears to be a need for more coopera- 
tion and understanding between laboratory project managers 
and contracting personnel. At NELC, various methods could 
be used to promote a more effective interface between the 
contracting specialist and the project office. One method 
would be to divide the projects among the contracting spe- 
cialists so that the individual specialist could more closely 
relate to specific projects, maintain close contact with his 
specific project managers and be better able to sec progress 

and anticipate project needs. 
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At the same time, every project manager should take 
advantage of opportunities to increase his knowledge of 
procurement procedures and internal/external requirements 
placed on the Supply and Contract Services Division. For 
example, in December 1973 a short three day research and 
development procurement course was offered at NELC which 
presented an ideal opportunity for project management types 
to increase their understanding of the procurement process. 
Only two of the eighteen NELC personnel who attended the 
course were directly related to project management. The 
majority of the class consisted of contracting/supply per- 
sonnel and the subject covered was basically a review for 
them. This type of course could be most beneficial to the 
typical project manager in furthering his knowledge of pro- 
curement procedures and improving his interface with con- 
tracting specialists. 

Project management personnel should also take advantage 
of management training opportunities whenever possible and 
higher level management should see that these opportunities 
are made available. Any training course which is offered 
should be well advertised throughout the organization and 
its intended purpose should be specified (i.e. procurement 
orientation for project management personnel, specific man- 
agement training, etc.). The opinion w as expressed that 
some type of management training would be nice but, as a 
project manager, there was not time to attend courses, etc. 

Be that as it may, the authors feel, that if a project manager 
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would take the time to acquire a few good management tools 
through training, the "fires" which require immediate and 
constant attention would be much less common and time 
consuming . 

A prime consideration in enabling laboratory project 
managers to understand and use the systems approach is in 
the attitude of higher level management. If senior man- 
agers realize that the transition from developmental 
engineer to project manager is not always an easy one and 
that some individuals should have a mangement orientation 
or training to more successfully meet organizational and 
project objectives, then management training will be made 
available and project managers and prospective project man- 
agers will be strongly encouraged to take advantage of it. 

Finally, in the opinion of the authors, the matrix 
organization as utilized at NELC is an effective and flexi- 
ble structure, well suited to meet both project and func- 
tional goals. With its many interfaces and subsystems it 
is the ideal structure in which a project manager can 
practice the systems approach to management. The project 
manager may "get by" with no management philosophy or the 
philosophy that what's good for his project is good for the 
total system. However, the authors believe that if a pro- 
ject manager will consciously practice the systems approach 
to management his job will be easier, his project will have 
a better chance for success, other subsystems' goals will 
be more easily met and the total system will benefit. 
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APPENDIX A: SOME ILLUSTRATIONS AND DISCUSSION OP PLANNING 

AND CONTROL TOOLS 

The following pages contain some general examples of 
planning and control tools and techniques which can be use- 
ful in managing a project, along with some specific examples 
of tools used by a laboratory project manager to plan for 
and control his project. Some examples are very simple 
and their purpose is one of illustration. However, some 
project managers could probably increase the value of their 
planning and control by thinking about how they might ap- 
ply something as simple as a plot of planned versus actual 
expenditures to their project. 

At the end of this appendix there is a brief discussion 
of PERT which is intended as a familiarization. An il- 
lustration of PERT is beyond the scope of this paper but 
a detailed explanation can be obtained from many sources, 
one of which is MIL-P-23189A (Navy) dated 25 October 1962, 
a milspec on PERT/Time and PERT/Cos t Management. 
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TRACKING EXPENDITURES VERSUS BUDGET 



It is not controlling to track cumulative expenditures 
as in the upper chart. Expenditures must be compared with 
planned expenditures (budget) as in the lower chart in order 
that deviations may be detected and corrective action taken. 
The upper chart gives a manager very little useful informa- 
tion. The lower chart, however, clearly points out that 
more money than planned is being spent and that something 
had better be done soon to correct the trend. 





ACTUAL EXPENDITURES 

PLANNED EXPENDITURES 
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The chart depicted below is an illustration of a chart 
used to track expenditures with funds budgeted (in this 
case budgeted means funds set aside for the project's use) 
funds actually expended and planned expenditures all shown 
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BAR CHARTS 



TASK 



TASK 



Bar charts are another tool which can be used to track 
progress and may be as simple or as detailed as desired. 
However, as can be seen from the two charts below, an indi- 
cation- of tasks completed (upper chart) is almost meaning- 
less compared to progress versus schedule (lower chart). 

The lower chart clearly points out that tasks 1 and 3 • are 
behind schedule while 2 is complete and 4 has been completed 
well ahead of schedule. 
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NETWORK AND MILESTONE CHARTS 



The following four pages are examples of typical mile- 
stone charts used by the WWMCCS Project Office primarily 
for planning purposes . The milestone charts are made up 
by the task leaders and submitted to the project manager 
for approval. Milestone charts are excellent tools to aid 
in the planning process but are also used to track the 
project . 

It is not intended that the reader interpret the 
figures, symbols, etc. on the charts, they are simply ex- 
amples of control tools in use by a particular project. 
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MILESTONE REPORTS 



An example of a typical milestone report is contained 
in the following seventeen pages. This particular mile- 
stone report was prepared by the WWMCCS Project Office 
to cover the week ending 7 December 1973 - The milestone 
report is an excellent control tool in that it gives an 
overview of the entire project (excluding funds) and al- 
lows the manager to see progress made and expected to be 
made in the future . 

It should be noted that milestones are explained and 
discussed in the report along with their probable impact 
on the project. The fact that a milestone was missed may 
or may not be significant, depending upon its relationship 
to other milestones and the project as a whole. 
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:19B 


ELINT SSD (Sects 1-3) 


F 




1/11 














'20B 


ELINT SSD (Prelim) 


S 




1/14 














' 21 B 


ELINT SSD (Prelim) 


P 




2/15 














22B 


ELINT Data Requirements 


P 




2/15 














23 B 


ELINT Design Review 


S 




2/19 














24B 


ELI NT Desion R 0 v i sw 


F 




3/1 














25B 


ELINT SSD ’"(Final f 


S 




3/4 














26B 


ELINT SSD (Final) 


D 




E 3/15 














27B 


ELINT Data Requirements (Final) 


D 




E 3/15 
















Previous FY-74 Milestones completed 




















S = Start P = Preliminary E 


= External Deliverable 




TOT A I Q 




*3 


0 


0 




F = Finish D = Deliverable * 


= Completed early 




1 L/ 1 r\ L. j 


I c. 


0 


C 


L 



MILESTONES MISSED (INCLUDE REASONS, EFFECT ON PROBLEM/PROJ ECT, REMEDIAL ACTION 

TAKEN, AND WHEN) FY~7h 1 2 ‘3 ? 

. TOTALS 



Ho. 216 - This milestone was missed due to delay in receipt of mail. Estimated 
completion date is 14 December 1973. No impact on the program is 
anticipated. Responsible code is Code 1130. 

Ho. 21 SB - This milestone was missed due to key person being on leave. Estimated 
start date is 10 December 1973. No impact on the program is anticipated. 
Responsible code is Code 5320. 
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U 

0 

< 

5 
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ED 




MILESTONE 




SCHEDULED 


REVISED 


ACTUAL 


ii 


L 


lo. 


' IDENTIFICATION 


1 


AN/UYK-4 Interface 


S 


1130 


9/4 




9/4 


X 








)6 


Dual CRT Switch 


S 




9/4 




9/4 


X 








5 


NSCC Interface 


S 




9/17 




*9/4 


X 








1 


OCR Trade-Off Analysis 


s 




9/17 




*9/4 


X 








)8 


BR-7C0 Interface 


D 




11/2 


11/30 


11/30 


X 


X 






8 


AN/UYK-4 Interface 


D 




n /2 




‘11/6 


X 




X 




'1 


NS0C Interface 


D 




n /2 




n/6 


X 




X 




9 


OCR Trade-Off Analysis 


D 




n /2 


11/16 


11/15 


X 




X 




0 


Functional Descrip Rev (West) 


D 




11/16 


12/7 






X 




i v 

A 


4 


Dual CRT Switch 


D 




11/16 


12/7 






X 




V 

A* 


16 A 


Functional Descrip Rev (East) 


S 




9/4 




9/4 


X 








I9A 


0CC 526/6CC-48 Interf Analysis 


D 




11/16 


12/7 






X 




X 


2A 


Functional Descrip Rev (East) 


D 




11/23 


12/14 






X 




• 
















29 


7 


2 






Previous FY-74 Milestones Ccrr.nl e 


ted 














i 





J; 


S = Start P - Preliminary E 


l xternal Deliverable 




totals 


S 


5 


3 


3 




F = Finish D = Deliverable 


= t.ompioiea 


eany 















.‘ilLSTONES MISSED (INCLUDE REASONS, EFFECT ON PnO CLEM/PR OJ ECT, REMEDIAL ACTION 
TAKEN, AND WHEN) 



FY-74 

TOTALS 



38 12 5 



o. 210 - This milestone was missed due to delay in typing. Estimated completion 
date is 14 December 1973. Minor impact on the program is anticipated. 
Responsible code is Cede 1130. , 

o. 209A - This document was rejected by project QA on 6 December. Estimated 
completion date is 14 December 1973. Minor impact on the program is 
anticipated. Responsible code is Code 1130. . , 

o. 214 - This milestone was missed due to underestimation of the complexity and ^ 
time required for completion. Estimated completion date is K Oece t 
1973. Minor impact on the program is anticipated. Responsible code is 
Code 1130. 
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PROBLEM MANAGER. CODE 1130 
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REVISED 


ACTUAL 
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IDENTIFICATION 
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ij c 

C1L7 


Ill 


BR Prog Prod & Unit C/0 


s 


5330 


10/1 




10/1 


X 




112 


BT Prog Prod & Unit C/0 


s 




10/1 




10/1 


X 




115 


TMP Prog Prod & Unit C/0 


s 




10/8 




10/8 


X 




116 


TUR Prog Prod & Unit C/0 


s 




10/8 




10/8 


X 




119 


PCM Prog Prod & Unit C/0 


s 




10/15 




10/15 


X 




120 


TFM Prog Prod & Unit C/0 


s 




10/15 




10/15 


X 




114 


TUR Program Specs 


D 




10/19 




10/19 


X 




124 


0MP Prog Prod & Unit C/0 


S 




10/22 




10/22 


X 




123 


MM Prog Prod & Unit C/0 


S 




10/22 




10/22 


X 




113 


TMP Program Specs 


D 




10/26 




*'10/26 


X 




109 


BR Program Specs c- 


D 




10/26 




10/26 


X 




110 


BT Program Specs 


D 




10/26 




*10/19 


X 




17 


PCM Program Specs 


D 




11/2 




11/2 


X 




*118 


TFM Program Specs 


D 




11/2 




11/7 


X 


X 


822 


CMP Program Specs 


D 




11/2 




*11/1 


X 




121 


MM Program Specs 


D 




11/9 


. 11/16 


11/13 


X 


X 


535 


ROTA S/S Integration 


S 




12/15 










fl36 


LONDON S/S Integration 


S 




12/15 










130 


BT Program Prod u Unit C/0 


F 




12/15 










K0 


System Inteqraticn 


S 




1/7 










26 


TMP Prog Prod S Unit C/0 


F 




1/11 










129 


BR Prog Prod & Unit C/0 


F 




1/11 










127 


PCM Prog Prod & Unit C/0 


F 




1/11 










134 


NORFOLK S/S Integration 


S 




1/14 










133 


TUR Prog Prod & -Unit C/0 


F 




1/25 










128 


TFM Proa Prod & Unit C/0 


F 




1/25 










132 


0MP Prog Prod & Unit C/0 


F 




1/25 










131 


KM Prog Prod & Unit C/0 


F 




1/25 
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S * Start P * Preliminary 
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1 5 
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F = Finish D = Deliverable 


* = Completed early 
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MILESTONE 


Si - o 

U H u 
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CJ 
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IDENTIFICATION 


c 
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RL V1SLU 
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5 


S o 
- u 


5 


01 


Install DFC-B/A Conv-MUX 


s 


4300 


7/2 




7/2 


X 






02 


DFC-B/A Conv-MUX Reprogramming 


F 




7/20 




7/27 


X 


X 




03 


Install DFC-B/A Conv-MUX 


F 




7/20 




7/27 


X 


X 




04 


Ship DFC-B/A Conv-MUX 


F 


, 


7/20 




7/20 


X 






05 


Checkout DFC-B/A Conv-MUX 


S 




7/23 


7/30 


7/30 


X 






06 


Checkout DFC-B/A Conv-MUX 


F 




8/21 




8/21 

/ 


X 
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DFCU Del ivery 


S 




9/4 




9/4 


X 


X 




03A 


Data to Code 6430 (DFCU) 


S 




9/4 




9/4 


X 






m 


PM- 1 6 Revision (DFCU) 


S 




9/4 




9/4 


X 






I0A 


DACOM Bypass Fab'n & Test 


S 




9/4 




9/4 


X 






iiA 


Data to Code 6430 (DACOM) 


S 




9/4 




9/4 


X 






I2A 


DFCU Del ivery 


F 




10/1 


11/2 


11/2 


X 


X 




ISA 


Data to Code 6430 (DFCU) 


F 




10/5 


11/S 


11/9 


X 


.X 




I4A 


PM- 16 Revision (DFCU) 


D 




10/5 




10/5 


X 






I5A 


DACOM Bypass Fab'n & Test 


F 




11/2 




11/2 


X 


i i 


| 


I6A 


Data to Code 6430 (DACOM) 


F 




11/2 




11/2 


X 






I7A 


NEDN/HIDN Installation 


S 




11/12 




11/12 


X 






I8A 


NEDN/NIDN Installation 


F 




12/14 












): 


S » Start P K Preliminary E 


» External Dc 


iliverable 


. 






, 1 


p 




F = Finish D = Deliverable * 


= Completed eariy 




TOTALS 
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1 


0 | 


MILLSTONES MiSS ED (INCLUDE R EASONS. EFFECT ON PRD LiLEM/PROJ ECT, REMEDIAL. ACT 1 DM 


FY-7m 










TAKEN, AND WHEN) 






. 




TOTALS 


17 


5 


0 



Milestone No. 105 date revised on 7/20/73. 
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MILESTONE DATE 
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REVISED 
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iB 

fB 



?B 

f B 

IB 

>5 

:b 

'B 

>B 

B 

B 



Install Development Facility 
Autodin Plan 
Install Rota (Lab) 

Install London (Lab) 

Install Development Facility 
Install Norfolk (Lab) 

Autodin Plan 
Install Rota (Lab) 

Install London (Lab) 

Install Norfolk (Lab) 
Interconnect System 
Interconnect System 
Prepare for Shipment 
Prepare for Shipment 



S 

S 

S 

S 

F 

s 

D 

F 

F 

F 

S 

F 

S 

F 



8/13 

9/4 

9/17 

9/24 

9/28 

10/1 

11/2 

11/30 

12/7 

12/14 

12/17 

1/4 

2/25 

4/5 



10/15 

2/1 

TBD 



8713 

9/4 

9/17 

9/24 

9/28 



X 

X 

X 

X 

X 



10/15 X 

*11/1 X 



X 




Previous FY-74 Milestones completed 

S = Start P = Preliminary E = External Deliverable 

F = Finish D = Deliverable * = Completed early 



TOTALS 



i 

7 



0 

0 



0 

3 



•ILCSTONES MISSED (INCLUDE REASONS, EFFECT ON PROBLEM/PROJCCT, REMEDIAL ACTION 
TAKEN, AND WHEN) 



FY-74 

TOTALS 



8 



0 



3 



1 



3 . T13B - This milestone was missed due to late supply of PDP11 equipment from 
NAVELEX. Estimated completion date is to be determined and will be 
reported when known. Minor impact on the program is anticipated. 
Responsible code is Code 1000. 
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j -1 — 


01 


A-B-A Hdwre Tech Man (Type II) 


S 


6430 


10/1 




10/1 


X 








02 


A-B-A Software Proj Manual 


S 




10/1 




10/1 


X 








03 


Elint L. D. Hdware Tech Man 


s 


• 


! 10/1 




10/1 


X 








06 


DFCS* Hdware System Tech Manual 


s 




1*0/23 




10/23 


X 








07 


DFCS Software Proj Man (TTY Int) 


s 




10/23 




10/23 


X 








08 


DFCS Software Project Man (LPInt) S 




10/23 




10/23 


X 








09 


‘.DFCS Software Project Man (TPInt) S 




10/23 




10/23 


X 








10 


DFCS Software Project Man (TRInt) S 




10/23 




10/23 


X 








04 


Elint L. D. Hdware Tech Man 


D 




■ 11/2 




11/2 


X 








05 


NELC Review (Ho. 104) 


s 




11/5 




41/5 


X 








11 


NELC Review (No. 104) 


F 




11/9 




11/9 


X 








12 


Elint L.D. Hdwre Tech Man (Update )S 




11/9 




11/9 


X 








14 


Elint L.D. Hdwre- Tech Man(Update) 


F 




11/26 




11/26 


X 








13 


NELC Review (No. 114) 


S 




11/26 




11/26 


X 








15 


NELC Review (No. 114) 


F 




11/30 




11/30 


X 








16 


A-B-A Hdwre Tech Man (Type II) 


F 




11/30 


12/7 


12/4 


X 


X 






17 


A-B-A Software Proj Manual 


F 




11/30 


12/14 






X 






18 


NELC Review (No. 116) 


S 




12/3 




12/4 


X 








19 


NELC Review (No. 117) 


S 




12/10 














20 


NELC Review (No. 116) 


F 




12/17 




*12/7 


X 








21 


A-B-A Hdwre lech Manual (Uodate) 


S 




12/17 














22 


NELC Review (No. 117) 


F 




12/17 












* 


23 


A-B-A Softwre Proj Man (Update) 


S 




12/17 . 














25 


A-B-A Hdwre Tech* Manual (Update) 


F 




12/24 














24 


NELC Review (No. 125) 


S 




12/24 














27 


A-B-A Softwre Proj Man (Update) 


F 




12/24 




■ 


T 








26 


NELC Review (No. 127) 


S 




12/24 














28. 


NELC Review (No. 125) 


D 




12/28 














29 


NELC Review (No. 127) 


D 




12/28 






■ 
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External Di 


e li v era bis 


T*/"S*T* AIC 


1 ft 


o 


r. 






F = Finish D = Deliverable * = 


Completed early 
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>01 

.>02 

.>03 

?04 

!05 

;06 

!07 

!08 


NEDN/NIDN Hdwre Tech Manual S 
NEDfl/NID.T Sftwre Proj Manual S 
NEDN/fl I Di’l Hdwre Tech Manual F 
NEDN/NIDN Sftwre Proj Manual F 
h'ELC Review (Mo. 203) S 
NELC Review (Mo. 204) S 
KELC Review (Mo. 203) F 
MELC Review (No. 2C4) F 


6430 


10/15 

10/15 

12/14 

12/14 

12/17 

12/17 

1/11 

1/11 

* 


i 


10/15 

10/15 

r _ 


X 

X 


y-J-J-- 


'D; S = start P ==• Preliminary E = External Deliverable 

F = Finish D = Deliverable * = Completed early 


TOTALS 


2 


0 


: 0 


0 
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109 

no 
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Comm Phase 1 SSD (Sect 1-2) 
Comm Phase 1 SSD (Sect 1-2) 
Comm Phase 1 SSD (Sect 1-3) 
Comm Phase 1 SSD (Sect 1-3)* 
Comm Phase 1 SSD (Preliminary) 
Comm Phase T SSD (Preliminary) 
Prep for Final Design Review 
Prep for Final Design Review 
Final Design Review 
Final Design Review 
Comm Phase 1 SSD (Final) 

Comm Phase 1 SSD (Final) 



5330 



11/5 

12/7 

12/10 

12/14 

12/17 

1/18 

1/21 

2/1 

2/4 

2/8 

2/n 

3/1 
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12/7 X 



/ 



J D: 


5 = Start 
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ANL I UMU 


2 






LI 


•01 


IDS Interface Design 


s 


5200 


7/2 




7/2 


X 








'02 


Central Table Design 


s 




7/2 




7/2 


X 








03 


Command Manual 


s 


• 


7/2 




7/2 


X 








04 


Central Table Design 


F 




7/27 




7/27 


X 








05 


System Segmentation Design 


s 




7/30 




7/30 


X 








06 


System Segmentation Design 


F 




8/31 




8/31 


X 








07 


Subsystem Specs 


s 




9/4 




9/4 


X 








08 


IDS Interface Design 


D 




E 9/28 


.10/5. 


10/5 


X 


X 






09 


Subsystem Specs 


D 




E 9/28 


10/5 


10/5 


X 


X 






10 


Command Manual 


D 




E 9/28 


10/19 


‘1 0/1 9 


X 


x 






11 


Module (Program) Specs 


s 




10/1 




10/1 


X 








12 


Test Data Base Development 


s 




10/1 




10/1 


X 








13 


Module (Program) Specs 


D 




E 11/16 




*11/13 


X 








14 


Program Prod & Unit C/0 


S 




11/19 




11/19 


X 








15 


Test Data Base Development 


F 




11/30 




* 11/20 


X 








16 


Test Plan Development 


S 




12/3 




12/3 


X 








17 


ISDS Prog Prod & Unit C/0 


F 




2/15 














18 


Test Plan Development 


F 




2/15 














19 


Subsystem Integration 


S 




2/18 














20 


Module (Prog) Maint Manual 


S 




2/18 














21 


Subsystem Integration 


D 




3/29 














22 


Module (Prog) Maint Manual 


D 




4/26 














01 B 


Bui k Update Program Specs 


S 


• 


11/26 


• 


11/26 


X 








02B 


ELI NT Data Base Specs 


S 




1/14 














03 B 


Bulk Update Program Specs 


D 




1/18 • 














04 B 


Bulk Update Prog Prod & Unit C/0 


S 




1/21 














05B 


Bulk Update Prog Prod & Unit C/0 


F 




2/18 














06 B 


Revise Ccmd Manual a SSD • 


S 




2/21 














07 B 


ELIDE Data Base Specs 


D 




3/15 














08 B 


Revise Ccmd Manual & SSD 


D 




E 3/29 


- 












5: 


s = Start P 21 Preliminary E » 


External D e 


iliverablo 






1 "7 




n 






F = Finish 0 = Deliverable * = 


Completed early 
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P ri a 










U 
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3 r ■ D 
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MILLSTONE 


w - 0 
, LJ ^ o 


c 


rucniM Fn 


pFv/icrn 


ACTUAL 


n 

< 




CJ 


s 6 s 


to. 


identificai ion 


VL 


J 


L n L-UU ULU 


r\t. V 1 jUL J 


r\ L 1 u/vl 




CJ O 

mo 


o 


u ^ 2 


)l 


1/0 Formats for 2.0 Test Progs 


F 


230 




7/13 




7/13 


X 








)5 


CA 2.0 S/S Test Plan (I) 


S 






9/17 




*9/1 0 


X 








)6 


CA 2.0 S/S Test Plan (I) 


D 






9/28 




*9/21 


X 








)8 


CA 2.0 S/S Test Proc & Data (II) 


S 






10/1 




10/1 


X 








)9 


IMP 2.0 S/S Test Plan (I) 


S 






10/1 




10/1 


X 








0 


COMM 2.0 S/S Test Plan (I) 


s 






10/1 




10/1. 


X 








,1 


IMP 2.0 S/S Test Plan (I) 


D 






10/12 




10/12 


X 








2 


COMM 2.0 S/S Test Plan (I) 


D 






10/12 




10/12 


X 








3 


2.0 System lest Plan (I) 


S 






10/15 




10/15 


X 








4 


IMP 2.0 S/S Test Proc & Data (II) S 






10/15 




10/15 


X 








)2 


APS 2.0 S/S Test Plan (I) 


S 






10/15 




JO/15 


X 








6 


COMM 2.0 S/S Test Proc & Data ( I I ) S 






10/15 




To/15 


X 








7 


CA 2.0 S/S Test Proc & Data (II) 


D 




r- 

lL 


10/19 


10/26 


10/26 


X 








8 


2.0 System Test Plan (I) 


D 






10/26 




*10/25 


X 








13 


APS 2.0 S/S Test Plan (I) 


D 






10/26 




*10/24 


V 

A 








9 


2.0 System Test Proc & Data (II) 


S 






10/29 




10/29 


X 








14 


APS 2.0 S/S Test Proc & Data (II) 


S 






10/ 2 9 




10/29 


X 








'0 


IMP 2.0 S/S Test Pro.c & Data (II) D 




7 


11/2 




11/6 


X 


X 






:3 


CA 2.0 S/S Test Anal Rpt (III) 


S 






11/5 


11/19 


11/19 


X 








P 


COMM 2.0 S/S Test Proc a Data ( I I )D 




— 


11/9 




*11/6 


X 








'4 


2.0 System Test Proc & Data (II) 


D 




7 


11/16 




11/16 


X 








17 


APS 2.0 S/S Test Proc & Data (II) D 






11/16 




11/16 


w 

A 








!5 


IMP 2.0 S/S Test Anal Rpt (III) 


S 






11/19 




11/19 


X 








:7 


CA 2.0 S/S Test Anal Rpt (III) 


D 




7 


11/21 


12/14 
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COMM 2.0 S/S Test Anal Rpt (III) 


S 






11/26 




11/26 


X 








"8 


2.0 System Test Anal Rot (III) 


S 






12/3 


" ■ 


12/3 


X 








5 


APS 2.0 S/S Test Anal Rpt (III) 


S 






12/3 


12/17 






\ 




'9 

0 


IMP 2.0 S/S Test Anal Rot (III) 


D 




z 


12/7 


12/14 








. 




COMM 2.0 S/S Test Anal Rot (III) 


D 




: 


12/14 




*12/7 


X 








1 


2.0 System Test Anal Rpt (III) 


D 






12/21 












:1 


APS 2.0 S/S Test Anal Rot (III) 


D 






12/21 
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F = Finish D = Deliverable * = 
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V o i 
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CA 1.7 Subsystem T&E - S 


1130 


7/9 




7/9 


X 








)2 


IMP 1 . 7 Subsystem T&E S 




'. 7/9 




7/9 


X 








)3 


CA 1.7 Subsystem T&E F 




7/13 




7/13 


X 








)4 


IMP 1.7 Subsystem T&E F 




7/13 




7/13 


X 








15 


1 . 7 System T&E S 




7/16 




7/16 


X 








)6 


COMM 1 .7 Subsystem T&E S 




7/16 




7/16 


X 








) 7 


1.7 System T&E F 




’7/20 




7/20 


V 

A 








)8 


COMM 1 .7 Subsystem T&E F 




7/20 




7/20 


X 








)9 


APS 1.7 Subsystem T&E S 




8/13 




8/13 


X 








10 


APS 1.7 Subsystem T&E F 




*8/17 




v B/17 


X 








3 


CA 2.0 Subsystem T&E S 




10/29 


11/5 


11/12 


X 




X 




4 


CA 2.0 Subsystem T&E F 




11/2 


11/9 


11/16 


X 




X 




P 


IMP 2.0 Subsystem T&E S 




11/12 




11/12 


X 






' 


7 


IMP 2.0 Subsystem T&E F 




11/16 




11/16 


X 








16 


COMM 2.0 Subsystem T&E S 




• 11/19 




* 11/12 


X 








j!8 


COMM 2.0 Subsystem T&E F 




11/21 




*11/16 


X 








19 


2.0 System T&E S 




11/26 




11/26 


X 








il 


APS 2.0 Subsystem T&E S 




11/26 


12/13 








X 




20 


2.0 System T&E F 




11/30 




11/30 


X 








12 


APS 2.0 Subsystem T&E F 




11/30 


12/14 








X 




m 


1.7 System Re-Test & Eval ' S 




8/6 




8/6 


X 








m 


COMM 1.7 Subsystem Re-Test & Eval S 




8/6 




8/6 


X 








I0A 


1.7 System Re-Test & Eval F 




8/10 




8/10 


X 








1 1 A 


COMM 1.7 Subsystem Re-Test & Eval F 




8/10 




8/10 


X 
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Previous FY-74 Milestones completed 
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CONFIGURATION CONTROL 



The following three pages are examples of forms used 
by the WWMCCS Project Office in tracking and controlling 
engineering changes within the project. Requiring a for- 
mal process such as this when engineering changes are 
performed maintains the necessary checks and balances on 
changes to the design. It allows the project manager to 
track the actual make-up of the equipment being developed. 
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ENGINEERING CHANGE ORDER 



ECO No. 


Date 


(Seme cs ICR Ho.) 




1. ECO TITLE 




(Same os L CR) 





2. IMPLEMENTATION SCHEDULE 
Documentation 

Program Development 

Hardv'are Changes 



Start Date 



Completion Date 



System Version 
(IOC, etc.) 



Phase (I or 11) 



Release Date 



(/. TUch ccpy of re vise d bubble chert referring this charge) 



3. SYSTEM DESIGN SPECIFICATIONS 

Thu pzrj£*jph v,tll cu'tr :m the jh.v//i desitn specifications for each function requirim modification. This drsfpt will be prepared consistent 
with the OS'S pcrforr.jr. ,e jnJ design specific jt»on s and development for hte epprupuste version, h unctions *.?// be specified separately cj 
h the System Design Specif icutioru to ease the future update of ti*u document. 



4. HARDWARE CHANGES 

ilerdmue etu.-^es required v.:.'/ be noted u-hh fh.-ulnr.nt comment! on butalUtlion due or other neeecary in formed on. 



5. DOCUMENTATION CHANGES 

(fust tt*s documents trait w;il nrqvi/e up^atcj 



6. T his change v.'ill lx: incor poroted in Ihe next revision of lV/A(s): 



‘•Irnplomcntotior. authorized :nd directed: 



J, C, C.ddwoli, Code l ) dO 



llf3^l£LC-4liiVM (5-73) 



108 




109 



FIELD ENGINEERING CHANGE REPORT 



FECR lio. 


Date: 


1. Originator: 


« 

% 


2. Description of Chengs: 



3. Reason for Change: 



4. Estimated Effects on Performance: 







Submitted: 














(On-Si to Team i.nnder) 




Forwarded: ... ... . 


1 

1 

*o 

O 

4-1 

o 


(Task Leader) 




(Project Manaqor) 




i 

no 1 



PROGRAM EVALUATION AND REVIEW TECHNIQUE (PERT) 



PERT was developed for the Navy’s Polaris missle project 
in 1958 and is credited with playing an important role in 
bringing missies into operation two years earlier than an- 
ticipated. PERT is basically a Critical Path Method of 
planning and controlling using a probability distribution 
to estimate most likely path lengths. 

PERT is an excellent tool by which a project manager 

can : 

• estimate the time at which each milestone in the 
project can be expected, 

• predict slippages and estimate the effect of slip- 
pages , 

• select the "critical path" of those activities which 
cannot be delayed without jeopardizing the entire 
project , 

• force the project manager to draw a network and 
thereby think about his planning task, 

• logically show how events relate. 

PERT has faults, not the least of which is its complexity, 
but some variation of the critical path network can be used 
by every project manager as a tool to assist in planning for 
and controlling his project. 
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